home *** CD-ROM | disk | FTP | other *** search
/ Multimedia Selection / Multimedia Selection Volume One - CD-ROM / MULTIMEDIA SELECTION____________.ISO / grafica / dos / virtreal / doc / figure.doc < prev    next >
Encoding:
Text File  |  1992-08-08  |  6.6 KB  |  139 lines
  1.                               Figure File Format
  2.                           Version 2.00 -- June, 1992
  3.                             Written by Bernie Roehl
  4.  
  5.  
  6. The REND386 package now supports "figures" -- multi-segmented, hierarchical
  7. entities that are useful for animation and certain types of VR applications.
  8.  
  9. A figure is composed of a tree of "segments", each of which has a translation
  10. and rotation relative to its parent segment.
  11.  
  12. Each figure has a "root" segment, with no parent; from this root segment other
  13. segments descend, and from them still others descend, and so on.
  14.  
  15. For example, a human figure may have its pelvis as its root segment.
  16. Its children are the chest and the two upper-leg segments.  The upper legs
  17. each have one child segment, a lower leg.  The chest has three children -- the
  18. head, and two upper arm segments.  Each upper arm segment has a single child,
  19. the lower arm segment.  One could continue this to include hands, feet, fingers,
  20. toes, and so on.
  21.  
  22. The syntax of a figure file is simple, and very C-like.  It consists of a series
  23. of segments, each of which is a root segment.  Each of these root segments can
  24. possess a set of attributes, as well as child segments.  Each segment is bounded
  25. by braces.  Attributes are arbitrary text strings ending in a semicolon.
  26.  
  27. The attribute list is open-ended and extensible; programs that read figure files
  28. should ignore any attributes they don't recognize.
  29.  
  30. An example will make all this clearer.
  31.  
  32. {
  33.         comment = a human body;
  34.         name = pelvis;  comment = this is the name of the root segment;
  35.         {
  36.                 name = chest;
  37.                 { name = left upper arm; { name = left lower arm; }}
  38.                 { name = right upper arm; { name = right lower arm; }}
  39.                 { name = head; }
  40.         }
  41.         {
  42.                 name = left upper leg; { name = right lower leg; }
  43.         }
  44.         {
  45.                 name = right upper leg; { name = right lower leg; }
  46.         }
  47. }
  48.  
  49. In general, attributes are of the form "keyword = value;", though this is not
  50. a requirement.  The attributes used above are "name" and "comment".  Note that
  51. no program ever has to recognize a comment attribute, since by defintion
  52. comments should be ignored.
  53.  
  54. The attributes currently defined are as follows:
  55.  
  56.         name = somestring;
  57.         pos = x,y,z;
  58.         rot = x,y,z;
  59.         plgfile = filename scale x,y,z shift X,Y,Z sort type map filename;
  60.         segnum = someinteger;
  61.  
  62. The "pos" is the x,y,z displacement of the origin of this segment relative to
  63. the parent's coordinate system.  The "rot" is the rotation of this segment
  64. relative to the parent.  For root objects (which have no parent) these values
  65. are the absolute location and rotation of the entire figure in world
  66. coordinates.
  67.  
  68. The "plgfile" gives the name of a .plg file containing a geometric
  69. representation of the segment.  Note that the figure file format does NOT
  70. depend on .plg files; the reason the syntax is "plgfile = " rather than just
  71. "file =" is because a segment may have a large number of different
  72. representations and an application can choose whichever one they like.
  73.  
  74. The "scale", "shift", "sort" and "map" values are all optional, but in order
  75. to specify any of them you must specify all the preceeding ones (i.e. you
  76. cannot simply omit the scale parameter).  The "scale" values represent the
  77. amount by which the object should be scaled along each of its axes when it's
  78. loaded.  The shift value is the amount by which to shift the object's origin
  79. at load time.  The "sort" value is the type of depth-sorting to use for this
  80. segment's representation (default is zero).  The "map" value is the name of
  81. a file containing a list of unsigned values that are to be used in color
  82. remapping this segment.  If the top bit of a color value is set in a plg file,
  83. the bottom fifteen bits are used as an index into this map.
  84.  
  85. The difference between "shift" and "pos" is important.  The "shift" value is
  86. used to shift an object relative to its "native" origin, while the "pos" value
  87. is the amount by which the new origin should be displaced from the parent
  88. node's origin.
  89.  
  90. For example, suppose you want to represent the head of a human figure with a
  91. cube.  The cube may, in the .plg file, be defined with its (0,0,0) point at
  92. one corner.  Clearly, this origin is inconvenient for the head, since if the
  93. origin is centered over the neck of the figure then the head will be displaced
  94. to one side.
  95.  
  96. Alternatively, the cube might be defined with its (0,0,0) point
  97. at its geometric center.  However, this is also impractical; your head 
  98. should not rotate freely about its center.  If it does, stop reading this
  99. document immediately and seek medical attention.
  100.  
  101. What you to do is shift the cube so that its origin lies below the center
  102. of the cube, where your "neck joint" is.  That's what the "shift" value
  103. in the "plgfile" attribute specifies.
  104.  
  105. Important note: objects rotate about their [0,0,0] point as loaded.
  106.  
  107. The "pos" attribute specifies where this neck joint is in relation to the
  108. origin of the chest segment.  If your chest were longer vertically, then the
  109. "pos" attribute of the head segment should be increased in the Y direction
  110. (for example).
  111.  
  112. The "segnum" attribute associates a simple integer value with a segment,
  113. which can subsequently be used to refer to the segment when manipulating
  114. it.  (See the documentation on set_readseg_seglist() in the current version
  115. of the devel.doc file).
  116.  
  117. The "minx", "maxx", "miny", "maxy", "minz" and "maxz" values specifiy the
  118. limits on translational movement for the segment relative to its parent;
  119. if these values are not specified, then there are no limits.  Similarly
  120. the "minrx" and other "minr?" values are used to specify rotational limits
  121. in degrees.  The translation limits are long (32-bit) signed integers, the
  122. rotation limits are floating-point numbers.
  123.  
  124. Note that a figure file can in fact contain a series of segments; each of
  125. these is a root segment, so a figure file can in effect store a complete
  126. scene description (excluding lights and "cameras", though conceivably these
  127. could be added to the specification with little or no difficulty).
  128.  
  129. Comments on possible extensions to the figure file specification are welcomed;
  130. in particular, if you define new attributes please register them through us,
  131. to avoid future incompatabilities.
  132.  
  133. You can contact me broehl@sunee.uwaterloo.ca or via the rend386 mailing list.
  134. To subscribe to the list, send mail to rend386-request@sunee.uwaterloo.ca and
  135. I'll be happy to add you.
  136.  
  137.                                 --Bernie Roehl
  138.  
  139.